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in which data of a certain source format are converted into 
data of a certain target format The conversions may also 
be bi-directional. The invention includes a method for per- 
forming data structure conversions, wherein a data struc- 
ture comprises at least two elements located in a prede- 
teimined order in the data structure. The data structure 
is defined by using a definition language, and it is repre- 
sented as a source bit string. During the conversion the 
source bit string is converted into a target bit string. The 
method for performing the data structure conversion han- 
dles the data structure elements in the same order as they 
are located in the data structure without parsing the source 
bit string. The avoidance of the parsing makes the method 
more elBficient than the prior art methods. In addition, the 
method decodes each data structure element and encodes 
it directly into the target bit string. Also the avoidance of 
unnecessary copying of data makes the method efficient 
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A method for performing data structure conversions 
Field of the invention 

The present invention relates to data conversions between 
5 INAP/MAP messages and certain other messages. The INAP/MAP mes- 
sages are used in the SS7 network, and the other messages are used m 
certain distributed systems. 

Baclcground of the invention 

The Object Management Group (OMG) consortium has defined an 
10 architecture temied Common Object Request Broker Architecture (CORBA)^ 
The CORBA architecture enables the distribution of applications on different 
kinds of platfomis. According to the client-server model, there are two kinds 
of applications: the client applications that request sen/ices and the server 
applications that offer the requested services. 

In CORBA architecture the sen^ices and computer units work to- 
gether so that the services are independent of the operating systems and the 
hardware platfomis. CORBA encapsulates the C++ code and data into ob- 
jects so that the objects are accessible by means of method invocationsHn 
this way a client can access objects located in another computer unrt The 
client does not know where the service takes place geographically, but only 
the name and interface of the objects providing the service. 

CORBA 2.0 Includes specifications for a functionality that is 
temied Object Request Broker (ORB). ORB enables transparent communica- 
tion between applications. The client and the server applications are sepa- 
rated from the mechanism used for communicating, activating, and stonng 
objects. Each computer unit which needs to communicate with other units 
has the ORB functionality. 

Intelligent Network (IN) is an architectural concept for the creation 
and provision of advanced telecommunications services. 

FIG 1 shows an example of IN architecture based on CORBA. 
The SS7 network can communicate with the Public Switched Telephone 
Networks (PSTNs) and the Public Land Mobile Networks (PLMNs). It can 
also communicate with CORBA through a bridge shown in FIG. 1. Further- 
more the SS7 network can communicate vrith the Internet via CORBA. 
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Besides protocols also abstract languages and special transfer 
syntaxes are needed. The abstract languages and transfer syntaxes define 
how the data are to be encoded and located in the messages. 

Interface Definition Language (IDL) is an abstract language used 
5 in CORBA. IDL specifies objects that compose an interface of a client appli- 
cation. 

Common Data Representation (CDR) Is a transfer syntax that 
maps IDL types, i.e. data types, to low-level representation for on-wire- 
transfer between ORBs. 

10 The SS7 network delivers messages that are specified using data 

structure language named the Abstract Syntax Notation One (ASN.1). The 
ASN.1 language is capable of specifying complex recursive data types and is 
used to describe the content and context of messages. During transfers over 
the SS7 network, the values of the ASN.1 types are encoded according to a 

15 transfer syntax such as Basic Encoding Rules (BER). The BER enables a 
series of recursive elements, comprised of Tag. Length, and data fields. The 
Tag fields indicate what type of data is packed into the message, and the 
Length fields indicate the number of bytes of data within this particular part of 
the message. 

20 In order to convert data between different networks, certain kinds 

of mapping rules are also needed. The Telecom Task Force group in OMG 
has defined the mapping rules between INAP and IDL data definitions. In 
addition, the X/open Preliminary Specifications include an ASN.1 to IDL 
translation algorithm. The INAP/MAP messages of the SS7 network are 

25 inputs for generating the GlOP messages of CORBA, and vice versa. This 
message generation is executed according to the mapping rules. 

The Service Logic Environment (SLE) is an entity made for exe- 
cuting CORBA services. The SLE is equipped with an ORB functionality, 
which enables applications to provide services for other applications. 

30 As illustrated in FIG. 2. the SLEs conned the applications to 

CORBA. An Inter-Woricing Unit (IWU), shown in FIG. 2, is one part of the 
bridge, shown in FIG. 1. which connects the CORBA network to the SS7 
network. In this context, IWU refers to a process, not .necessarily to a com- 
puter unit. IWU is equipped with the ORB functionality as well as the SLEs. 

35 Therefore, IWU and the SLEs comply with GlOP. ESlOP, and MOP protocols. 
IWU communicates with the SLEs via CORBA using GlOP messages. 
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TCAP is a protocol as described above. In this paper, TCAP also 
refers to a process. As shown in FIG. 2, TCAP is the other part of the bridge 
connecting CORBA and the SS7 network. TCAP communicates with the SS7 
network using INAP or MAP messages. 
5 The bridge receives GlOP messages from an SLE, and INAP/MAP 

messages from the SS7 network. Receiving a message can be termed an 
event. The bridge creates a record of an event, which record includes data 
received in a message. Inside the bridge, IWU and TCAP may communicate 
with each other by transmitting records of events. 

10 A dialog refers to communication between two applications using 

data conversions. A dialog is composed of dialog primitives. The dialog primi- 
tives indicate the beginning of a dialog, the formation of a dialog, the con- 
tinuation of a dialog, and the end of a dialog. The dialog primitives may also 
transmit data belonging to a dialog. 

1 5 When a TCAP begin message is received from the SS7 network to 

the bridge, an association is fonned between an application executing in SLE 
and the SS7 layer in the bridge. This TCAP begin message is termed 
SS7Begin dialog primitive. Alternatively, the SLE can initiate the association 
between it and the SS7 layer in the bridge by sending an SLEBegin named 

20 dialog primitive. The association represents a dialog which has been estab- 
lished all the way from the SLE application to the application on the SS7 
network. Events relating to one association compose a dialog. The applica- 
tion on the SS7 network may be, for example, a call instance process execut- 
ing in a service switching point (SSP). The dialog could represent, for exam- 

25 pie, an IN control relationship between the SLE application and the SSP call 
instance. 

During an association. I.e. during a dialog, a CORBA application 
may execute remote operations for an SS7 application. The Remote Opera- 
tion Procedure (ROP) defines how the remote operations are invoked and 
30 how the results or enrors of the invoked remote operations are received. The 
ITU has defined remote operations for CORBA. These remote operations are 
called IDL operations. 

The ITU has also classified different kinds of INAP operations. The 
INAP operations define how remote operations of SS7 applications are in- 
35 voked and how the results or enrors of the invoked operations are received. 
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The Telecom Task Force group in OMG has defined mapping 
rules between the IDL and the INAP operations. The mapping mles are 
needed because CORBA applications and SS7 applications should be able 
to execute remote operations for each other. 

5 

In data conversions the data of a first format is converted to the 
data of a second format. The data of the first format as well as the data of the 
second format is stored In one or more data structures. A utility is a program 
or a part of a program which executes data conversion between certain data 

1 0 structures. Utilities compose a set which Is temned a utility set. Con^espond- 
ingly, messages of a certain protocol compose a message set. For example, 
the messages of the INAP protocol compose an INAP message set 

The utilities perform conversions from one encoding format to an- 
other. In this case encoding means, for example, how data structures are 

15 represented in the data communication between two entities. The aim is to 
provide conception of the structure and semantics of the data on the target 
side which is similar to the source side. 

The present invention relates generally to the bridge shown above. 
Next, the object-oriented programming and compiler techniques utilized 

20 within the bridge will be discussed. 

JAVA and C++ are examples of object-oriented programming lan- 
guages. The objects may compose, for example, an Interface of a CORBA 
server application. Each object is defined as a class, which includes some 
data and methods for handling that data. A class may also include methods 

25 for handling the data of other classes. 

A compiler is a program that reads one or more input files and 
writes an executable code, or a source code, in one or more output files. The 
executable code may act, for example, as a utility set offering conversions 
between different data definitions. A compiler itself, and the files read and 

30 processed by the compiler, may include various classes. 

More specifically, the invention concerns converting BER encoded 
ASN.1 data structures into the CDR data structures, and vice versa. The 
BER encoded ASN.1 data structures are named briefly as BER data struc- 
tures and said conversions are named briefly as BER-CDR conversions. The 

35 BER-CDR. conversions are executed in the IWU shown in FIG. 2. 
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Each utility can execute the BER-CDR conversion between an 
IDL-based interface definition and an ASN.1 -based interface definition. There 
could be several versions of both types of interfaces. Thus a utility executes 
the conversion between a certain version of the interface defined by the IDL 
5 and a certain version of the interface defined by the ASN.1 . 

The interfaces could correspond to. for example, a certain MAP, 
INAP, or CAP version and their interface which is based on ASN.1 or IDL 
definitions. For instance, a utility could perform a conversion related to CAP 
(Camel Application Protocol). It could perform the conversion between the 
10 CDR encoding of a data type in the IDL interface and the BER encoding of a 
data type in the ASN.1 interface for CAP version 3. 

There are older and newer versions of I NAP/MAP message sets. 
Each utility can execute the BER-CDR conversion between a data structure 
of a certain GlOP message version and a data structure of a certain 
15 INAP/MAP message version. Thus, a great many utilities for the BER-CDR 
conversions are needed to enable conversions between each GlOP and 
INAP/MAP message set versions. 

Snacc is an example of a known freeware compiler which can be 
utilized in the BER-CDR conversions. As any compiler, the Snacc comprises 
20 at least the lexical analyzer, grammatical parser, and code generator. The 
lexical analyzer extracts grammatical tokens from the input stream. In this 
case, the input stream contains BER encoded ASN.1 data structures. 

The Snacc compiler uses its embedded BER library for generating 
a C++ code. The BER library has the functionality to convert BER data struc- 
25 tures into ASN.1 C++ classes, and vice versa. 

The Snacc compiler generates the C++ code for BER-CDR con- 
versions. The C++ code includes the following method calls of the BER li- 
brary: 

- BEncPdu 
30 - BDecPdu 

- BEnc 

- BDec 

- BEncContent 

- BDecContent 
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In these method names "Enc" refers to encoding and "Dec" refers 
to decoding. "Pdu" refers to a Protocol Data Unit, which is a block of data 
transmitted in the network. 

The procedure hierarchy structure of the generated code corre- 
5 spends to the structure of the ASN.1 data types presented as input to the 
Snacc compiler. Thus, depending on how the data types have been nested, 
the encoding routines of different data types call each other. For example, if 
datatypel contains datatype2 in its structure, the encoding function of 
datatypel calls the encoding function of datatype2. 
10 Every C++ class generated is derived from a base class named 

AsnType. The code generation is executed one data structure at a time and 
one field of the data structure at a time. 

For example, if the type of the field is integer, a class named As- 
nlnt is used. Thus, the type of the field determines which derived class of the 
15 AsnType base class is used in the code generation. 

The Orbix library (produced by a company named lONA) is an ex- 
ample of a known tool which can be utilized in the BER-CDR conversions. 
The Orbix library uses its embedded CDR library for generating C++ code. 

The CDR library has a functionality to convert CDR data structures 
20 into IDL C++ classes, and vice versa. 

FIG. 3A shows how the utilities for the BER-CDR conversions are 
generated in prior art. The generation of the utilities consists of at least three 
phases that are marked 1 to 3. The second phase is further divided into three 
sub-phases 2A, 28, and 2C. 
25 Thus the Snacc compiler can be used to generate the C++ code 

for phase 1, in which BER encoded data structures are converted to ASN.1 
classes or vice versa. Correspondingly, the Orbix library can be used to gen- 
erate the C++ code for phase 3, in which IDL C++ classes are converted to 
CDR encoded data structures or vice versa. 
30 In prior art, there is no tool for phase 2, i.e. the translation phase. 

Therefore a programmer has to write: a) a program "2A" for translations be- 
tween the ASN.1 C++ classes and ASN.1 instances, b) a program "28" for 
translations between the ASN.1 instances and IDL instances, and c) a pro- 
gram "2C" for translations between the IDL instances and IDL C++ classes. 
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The following example describes what kind of definition files the 
NAC compiler reads. The example concems an "InitialDP" named operation 
which is defined in "IN Capability Set 1 ". 

The definition for the "InitialDP" operation may be in a file named 

5 "operation. asn": 

CSIOPErationTypes DEFINITIONS ::= 

InitialDP ::= OPERATION 
ARGUMENT InitialDPArg 
10 ERRORS { 

...} 

InitialDP OPE OBJECT { 
&Arg InitialDPArg 
&Err{ 

15 ••> 

The definition for an "InitialDPArg". which is printed in the "opera- 
tion.asn" file, is given in another file that may be named "argument.asn". The 
definition for the "InitialDPArg" is given in an "argument.asn" file as: 
20 InitialDPArg ::= SEQUENCE { 

serviceKey [01 ServiceKey. 

redirectionlnfomiation [301 Redirectionlnfonnation 

The following two examples concem the conversion of the "Ini- 
tialDpArg- named data structure which is showed above, and which is BER 
enccxied. We may assume that also the corresponding CDR data structure is 

named the "InitialDpArg". r kw aoih 

30 The Snacc compiler processes the data structure field by field. 

This processing depends on the type of field. For example. "'nitialDpArg 
data structure contains a field which is named a "serviceKey". When the 
Snacc compiler has read the "serviceKey" field, the Snacc compiler gener- 
ates C++ code so that the BDecContent method of the Asnlnt class is called 
35 because the "serviceKey" field is the integer type. 
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The C++ code processing also depends on whether a field In- 
cludes a data structure or not, i.e. on whether the processed data structure is 
nested or not. If the field of the data structure includes a data structure, the 
data structure included is handled in the same way as the field itself. 

5 

Example 1: Generating a C++ code which converts BER to CDR 
(see FIG. 3A). 

In phase 1, the BER data staicture is the input and 
ASN.1 C++ classes are the output of the phase. The Snacc com- 
^ 0 piler generates a C++ code for each field of the InitialDPArg class 

so that the C++ code includes the following method calls of the 
BER library in the following order: 

- the BDecPdu and BDec method calls of the Ini- 
tialDp-Arg class, 

.,5 - the BDecContent method call of the InitialDpArg 

class, which in turn calls the BDecContent 
method of the AsnType class. 
In sub-phases 2A, 28, and 2C, the ASN.1 C++ classes 
are the input and the IDL C++ classes are the output. 
20 In phase 3, the IDL C++ classes are the input and a 

CDR data structure is the output of the phase. Method calls in the 
Orbix library are executed for each IDL C++ class. 

Example 2: Generating C++ code which converts CDR to BER 
25 (see FIG. 3A). 

In phase 1, the BER data structure is the input and 
ASN.1 C++ classes are the output of the phase. The Snacc com- 
piler generates a C++ code for each field of the InitialDPArg data 
structure so that the C++ code includes the following method calls 
30 of the BER library in the following order: 

- the BEncPdu and BEnc method calls of the Ini- 
tialDpArg class, 
. the BEncContent method call of the InitialDpArg 
class, which in turn calls the BEncContent 
35 method of the AsnType class. 

The other phases are same as above. 
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A C++ code is generated for several output files, and each output 
file is compiled by a C++ compiler. This compilation results in a program 
tenned "utility". Each utility executes data conversions between certain data 
structures. In respect to examples 1 and 2, the compilation results in a utility • 

5 which converts the "InitialDpArg" BER data structure into the "InitialDpArg" 
CDR data structure and vice versa. 

FIG. 3C shows that the BER encoded data is at first instantiated to 
ASN.1 instances. Then the ASN.1 instances are instantiated to IDL in- 
stances, and lastly, the IDL instances are extracted to CDR encoded data. 

10 Because of ASN.1 and IDL instances, there is a lot of data copying when 
executing BER-CDR conversions. 

There are several drawbacks relating to the prior art BER-CDR 
conversions. 

15 The first drawback is a lack of suitable utilities for BER-CDR con- 

versions. Consequently, customers of the SS7 network shown in FIG. 2 are 
able to use only those applications of CORBA which are supported by utilities 
for certain message sets. Con-espondingly, customers of CORBA (network) 
are able to use only those applications of the SS7 network which are sup- 
20 ported by suitable utilities. The utilities for different message sets, i.e. the 
utilities for different data formats, are difficult to produce. Therefore, quite a 
few applications are usable for the customers of different networks. 

The second drawback is that the utilities are quite Inefficient. The 
generated C++ code of the utilities includes a lot of data copying from one 
25 data structure to another data structure. This copying makes the utilities 
inefficient and so that the usable applications of the CORBA and SS7 net- 
work operate slowly, which in-itates the end users of the applications. 

The third drawback is that the utilities are poorly manageable. 
There are many dialogs to be handled simultaneously, and a utility suitable 
30 for an event of a current dialog should be found automatically. Therefore, a 
runtime system of IWU. or some other system, should manage the utilities. In 
prior art, a lot of designing and programming is needed to create a system 
that detemiines which utility is the right one for the cun-ent conversion. This is 
another reason why quite a few applications are usable for the customers of 
35 different networks. 
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Summary of the invention 

The first objective of the invention is to improve the availability of 
services for the end users. This concerns the services located in one network 
and Intended for customers of some other network. Then, for example, cus- 
5 tomers of the SS7 network can use more services offered by CORBA, and 
customers of CORBA can use more services offered by the SS7 network 
which have not been available to them up now. 

The second objective of the invention is to enable the services of- 
fered services to operate faster than nowadays, e.g. CORBA services used 
1 0 from the SS7 network via a bridge. 

The third objective of the invention is to maximize the automation 
of the maintenance of a bridge. Then, for example, the bridge can be 
adapted for a new message set without programming. Also, automated main- 
tenance of the bridge Increases the availability of the services. 
15 The objectives of the Invention can be accomplished by using the 

solutions defined in the patent claims. 

The present invention relates to any conversions, in which data of 
a certain source format is converted into data of a certain target format. For 
Instance, the source format may be BER and the target forniat CDR. Conver- 
20 slons may also be bi-directional. 

In an embodiment of the invention, the coding rules indicating the 
encoding for data type definitions in the target fomiat, i.e. in the target encod- 
ing fonnat, can also be represented as a mapping between data types in 
different definition languages. The actual target encoding fomiat for the data 
25 types defined in the first definition language are then obtained as follows: first 
mapping the data stmcture definitions in the first definition language to conre- 
sponding definitions in the second definition language and then using the 
information on the encoding of the data type definitions of second definition 
language in the target encoding fonnat. 
30 For instance, ASN.1 data type definitions are converted to IDL and 

then infomiation on the CDR encoding of the IDL data types is used for the 
target fonnat encoding of the data structure definitions. Thus, there is 
a mapping from ASN.1 data types to IDL data types. The mapping maps a 
data type of a first definition language to a data type of a second language. 

35 
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For instance. ASN.1 data type SEQUENCE is mapped to IDL 
"struct" data type and SET OF Is mapped to IDL "sequence" data type: 

ASN.1 definition 

NameTree SEQUENCE { rdnlnfo RDNINFO. 

children SET OF NameTree } 



is mapped to 

struct NameTreeType { RDNInfoType rdnlnfo; 

sequence <NameTreeType>children; } 

Alternatively, a data type in the first definition language could be 
mapped to a set of embedded data type definitions in the second definition 

language. ^ j. a 

For instance, this could mean that an ASN.1 data type termed 
CHOICE is mapped to a set of definitions comprising: 1) an "enum" definition 
to define the types of elements that can be present in the stmcture. 2) a 
union definition to indicate which of the said elements is actually present in 
one instance of the data type, and finally 3) the definitions for the elements of 
CHOICE. This is illustrated below with an example: 

ASN.Idefinition 

Context ::= CHOICE { id INTEGER, data EXTERNAL } 

is mapped to 

30 enum ContextTypeChoice { idChoice, dataChoice }; 

union ContextType switch (ContextTypeChoice) { 

case idChoice: ASNIJnteger id; 

case dataChoice: ASN1_Extemal data; }; 



20 



25 



35 in IDL. 
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The present invention includes a method for performing data struc- 
ture conversions, wherein a data structure comprises at least two elements 
being located in a predetemiined order in the data structure. The data struc- 
ture is defined by using a definition language and it is represented In as a 
5 source bit string. During the conversion the source bit string is converted into 
a target bit string which represents the con-esponding data structure. The 
method for perfonning data structure conversion comprises the following 
steps: 

- browsing the source bit string, 

10 - identifying in the source bit string each data stmcture element 

of the data structure, and 

- handling the data staicture elements in the same order as they 
are located in the data structure without parsing the source bit 
string; In addition, the handling is executed so that each data 

15 structure element is encoded directly into the target bit string, 

thus avoiding unnecessary copying of data. 

The present invention further includes a program, i.e. a utility for 
executing a certain data structure conversion. Utilities compose a utility set. 

20 

The present invention further includes a compiler which creates 
the utility set. The compiler creates the utility set by using one or more defini- 
tion files and coding rules. The coding mies provide information about data 
types and data stmctures of different fomnat. For instance, the coding rules 
25 provide infomiation about how certain ASN.1 data stmctures are encoded In 
CDR. The coding rules may concern low level data types such as Integers, 
octet string, sequences, and choices. In the case of a sequence, the mapping 
rules may indicate how the start of the sequence, the end of the sequence, 
and the presence of Individual elements are encoded in the sequence. The 

30 coding rules may be part of the executable code of the compiler. The com- 
piler may also read at least part of the coding rules from a set of files. 

In the following it is assumed that the coding rules are stored in 
two class libraries, which are termed "first class library" and "second class 
library". The compiler reads at least two class definitions: one from the first 

35 class library and one from the second class library. Then the compiler gener- 
ates a class definition which is temned "wrapper class". 
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The wrapper class includes at least one method which calls at 
least one method of the source class and one method of the target class. The 
compiler writes the classes read, and the wrapper class generated in an 
output file set. After the output file set is compiled, the utility set for conver- 

5 sions is created. 

The compiler generates a second output file for identification re- 
cords. Each identification record includes a pointer to a utility and an attribute 
for storing the ID (identifier) of the utility. The identification records are used 
for identifying the utilities which are created by the compiler according to the 

10 present invention. 

The identification records generated into the second output file 
operate as an index through which each utility can be obtained. When the ID 
of a utility is found In some identification record, the utility is obtained by 
using the pointer of the identification record. 

15 The compiler further generates a third output file for mapping 

rules. These mapping mles are used when determining which operations, or 
which data definitions, are analogous with each other. 

The compiler further generates a fourth output file for an initializa- 
tion file set. A certain initialization process reads the initialization file set and 

20 creates a fifth output file for context set records. The context set records are 
used, for example, to identify a message set of a message. 

The present invention further includes a system for using the utility 
set created by the compiler. The said system may operate as a bridge be- 
25 tween two networi^s, such as CORBA and the SS7 network. The system 
uses the utility set through a selection mechanism based on the above- 
mentioned output files of the compiler 

- the identification records (in the second output file), 

- the mapping rules (in the ttiird output file), and 
30 - the context set records (in the fifth output file). 

The system handles dialogs between applications, and it executes 
the data conversions needed. By using the selection mechanism, the system 
obtains pointers to the identification records, from where the system obtains 
35 pointers to an appropriate utility intended for a current data conversion. 
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Brief description of the drawings 

The invention is described more closely with reference to the ac- 
companying drawings, in which 

5 Figure 1 illustrates CORBA architecture. 

Figure 2 illustrates IWU as a bridge between the SS7 network and CORBA. 
Figure 3A depicts bi-directional BER-CDR conversion in prior art according 

to the present invention. 
Figure SB depicts the bi-directional BER-CDR conversion, 
10 Figure 4A depicts the compiler according to the invention, and the input 
which it reads and the output which it generates. 
Figure 4B depicts steps in data conversion and the use of mapping rules. 
Figure 5 presents objects of a mntime system used in IWU. 
Figure 6A depicts the compiler according to the invention which is used for 
15 BER-CDR conversions. 

Figure 6B depicts how MSD list records are compared to the SSTBegin (or 
SLEBegin) event. 

Figure 6C depicts attributes of the SS7Begin (or SLEBegin) event and cone- 
sporiding parameters of the MSD list records. 

20 Detailed description of flie invention 

A compiler named "NAC" generates the utilities for the BER-CDR 
conversions. However, the ideas of the invention can also be used in other 
compilers which generate utilities for data conversions. 

FIG. 4A depicts the compiler according to the invention, and the 
25 inputs which ft reads and the output which ft generates. The operation of the 
compiler is first discussed generally, without regard to the practical type of 
conversion performed. 

The compiler reads: 

- the definition file set. 

30 - the class definitions from a first class library, and 

- the class definitions from a second class library. 
The compiler generates: 

- the output file set, which includes classes; after compiling, the 
output file set results in the utilrty set for the conversions, 

35 . the second output file for the identification records of utilities, 
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- the third output file for the mapping rules, and 

- the fourth output file for the initialization file set, from which the 
initialization process creates the fifth output file for the context 
set records. 

5 The definition file set includes at least one ascii file which contains 

at least one definition. The definition file set of the NAC compiler includes 
ASN.1 definitions. The definition file of other compilers may include some 
other definitions. 

The first and second class libraries read by the compiler contain 
1 0 classes, I.e. the ascii text of class definitions. 

The second, third, and fifth output file are parts of the selection 
mechanism. Their content is described in more detail as follows. 

The second output file includes the identification records. Each 
identification record is equipped with at least one pointer pointing to a utility 
15 stored in the utility set. 

The third output file includes the mapping rules used to map dialog 
primitives corresponding to each other. For example, "SLEBegin" named or 
"SS7Begin" named dialog primitive starts a dialog between CORBA and the 
SS7 networi^. In tiiis case, the mapping rule maps SLEBegin and SS7Begln. 
20 The mapping rules are used as follows. When SLEBegin is initi- 

ated from CORBA, the mapping rules are read so that SLEBegin is used as a 
search key. When a mapping rule including SLEBegin is found, then also its 
substitutive, I.e. SSTBegin, Is found. 

There are many kinds of mapping rules possible, for example, 
25 mapping mles for operations, en-ors, type definitions, value definitions, etc. 
However, each mapping rule Includes a pair of operations, or a pair of errors 
etc. so that the objects of each pair correspond to each other. 

The fifUi output file contains tiie context set records, which are 
used to solve problems arising fi'om different versions of data structures. For 
30 example, different versions of a certain message set may include data struc- 
tures intended for the same purpose but having different names. Or different 
versions of a certain message set may include data staictures having the 
same name but different structures. 

Each context set record includes attribute values which identify a 
35 certain context. In addition each context set record is equipped with a pointer 
pointing to an identification record stored in the second output file. 
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In regard to message sets, such as GlOP message sets, each 
message includes certain attribute values comparable to the values of the 
context set records. When the attribute values are matched vy,ith the values of 
the context set records, an appropriate context set record is found. This is 
hov. the selection of an appropriate utility for the data conversion begins 

Depending on the system in which the utility set is to be used, the 
selection mechanism may include all or only some of the three parts, i.e. the 
identification records, the mapping rules, and the context set records 

A selection mechanism of the IWU runtime system includes all 
said parts of the selection mechanism. On the other hand, the selection 
mechanism may be simple and include, for example, only the identification 

records. ^^^^^^^^ ^^^^ ^^^^^ conversions is to identify from the 
received message the version of the protocol. Then it is possible to find the 
i corresponding versions of the utilities for the conversions. Different versions 
of the protocol may use different message sets which include different mes- 
sages with different data structures. Therefore, different versions of utilities 
are needed to convert different data structures. The selection mechanism 
relates a certain version of a utility to a certain version of the protocol. 
0 The identification of the protocol version is beneficially based on 

the inspection of message parameters, i.e. attribute values. 

For example, if a fictional system uses only one dialog pnmitive. 
the mapping rules are not needed. In addition. If the only dialog primitive is 
always transmitted in a same data stmcture. the context records are no 
•5 needed To show this, we make the following assumptions: 1) the utility set 
■ contains utilrties which are numbered from 1 to 99. 2) each identffication 
record includes an ID of one utility, wherein the ID is some number from 1 to 
99 and 3) the only dialog primitive in use in the fictional system includes a 
utility number from 1 to 99. When the fictional system is in operation, the 
30 system receives the dialog primitive and obtains the utility number stored in 
the dialog primitive. Then the system finds the identification record having the 
same utility number as an ID of a utility. Finally, the system obtains from the 
identification record a pointer pointing to the utility. 

Next we will describe in more detail the operation of the compiler. 
35 and after that the use of the selection mechanism. 
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It may assumed that the compiler reads the definition file set one 
definition at a time, and that at least some definitions contain class names. In 
addition, we assume initially that all definitions In the definition set belong to 
one message set. 

5 

When the compiler has read one definition from the definition file 
set, it executes the following steps: 

The compiler reads a definition from the definition file 
set and writes it Into a memory. 
10 The compiler parses bit strings of the read definition, 

whereby a parsed class name is obtained as a result of the 
parsing. 

The compiler reads a first class con-esponding to the 
parsed class name from the first class library and writes the first 
1 5 class into the memory. 

The compiler reads a second class corresponding to 
the parsed class name from the second class library and writes 
the second class into the memory. 

The compiler generates one wrapper class per each 
20 data structure to be converted, wherein the wrapper class Is 

adapted to call a method of the first class and a method of the 
second class, wherein the said methods handle data of the 
same context. 

After this, the compiler wrttes each wrapper class 
25 generated and the first class and the second class into an out- 

put file set, which consiste of at least, one file. 

The output file set is compiled by a suitable compiler; 
the compilation results in a utility of the utility set. 

30 When all definitions in the definition file are read and the above- 

mentioned steps are executed for each definition, the utility set is created. 
The utility set is used for converting data of the first fomiat to data of the 
second format, and vice versa. 

35 Related to the creation of the selection mechanism, the compiler 

further executes the following steps: 
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The compiler generates identification records, each 
of which is equipped vAth a unique identifier and at least one 
pointer pointing to a utility. 

The compiler writes into the second output file the 
5 identification records. 

The compiler generates mapping rules so that each 
mapping rule maps the identifier of the first dialog primitive and 
the identifier of the second dialog primitive, wherein the first dia- 
log primitive relates to data of the first format, and the second 
10 dialog primitive relates to data of the second format. 

Similarly, the compiler generates mapping rules for 
dialog primitives. 

In addition, the compiler generates attribute values 
for each mapping rule. These attribute values are used when 
15 the best match for a dialog primitive is to be found. 

The compiler writes the mapping rules into a third 

output file. 

For the above we have assumed that all definitions of the defini- 
20 tion set belong to one message set. The following is for cases when the 
definitions of the definition set belong to at least two message sets. 

Related to the creation of the selection mechanism, the following 
further steps are executed: 
25 The compiler generates data for the context set re- 

cords and writes the data into a fourth output file. 

When creating context set records, an initialization 
process reads the fourth output file. The initialization process 
creates context set records so that each record includes at 
30 least one pointer pointing to an identification record and written 

in the second output file. 

The initialization process writes the context set re- 
cords into the fifth output file. 

35 FIG. 4A and 4B illustrate the system according to the invention. 

The system uses the selection mechanism created by the compiler. 
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The system according to the invention may be a runtime system of 
IWU In that case, the system is part of a bridge which enables communica- 
tion between the SS7 network and CORBA. and the utility set used by the 
5 system comprises utilities for BER-CDR conversions. However, the systern .s 
not necessarily a runtime system, nor a part of a bridge. Nor must the utilities 
be utilities for BER-CDR conversions. 

There may be many versions of data formats which the system 
has to handle. First, the system must identify a version of a source format. 
1 0 and then, rt must determine an appropriate version for a target fonnat. 

There may be, for example, different versions of GlOP and 
INAP/MAP message sets which may include different BER and CDR data 

structures. . ^. , .. 

Generally, an application starts a dialog with a certain dialog pnmi- 
15 five, which may be located in a message or in a record of an event. In 
CORBA. for example, a dialog primitive named SLEBegin starts a dialog. 

When the system according to the present invention receives a 
dialog primitive, it has to find answers to the following questions: 
20 - What context set does the dialog primitive relate to? 

- What operation or data definition does it include? 

- What utility ought to be selected for conversion? 

The said context set may be a version of a message set. or of 
some other set of data structures. The selection mechanism obtains the 
25 answers to the above-mentioned questions. 

FIG. 4B Illustrates steps for the use of the selection mechanism. 
The following steps 41-46 refer to the steps shown In FIG. 4B. 

30 When a new dialog is starting: 

The system finds a context set record with the best 
match, wherein certain attribute values are the same as the at- 
tribute values of a dialog primitive received (step 41). 

Then the system obtains at least one pointer pointing 
35 from the matching context set record to an identification record 

(step 42). 
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Thus, steps 41 and 42 are executed only when a new dialog is 
starting. Step 41 is simple if the attributes of the dialog primitive and the 
parameters of the context set records have the same name. Then it is easy 
5 to find the attributes and the parameters having the same name. Step 41 
may also be as complicated as it is in the runtime system of IWU. 

When the dialog has started, the system has at least one pointer 
pointing to an identification record. During the dialog, the system receives 
1 0 and transmits dialog primitives and executes the following steps: 

The system obtains a first identifier from the dialog 

primitive received (step 43). 

By using the mapping rules, the system generates a 
second dialog primitive which corresponds to the first dialog 
-1 5 primitive received (step 44) . 

The system obtains data of the first fonnat from the 
first dialog primitive, and converts the data of the first format to 
data of the second format by using 1)' a pointer pointing from 
20 the context set record to an identification record, and then 2) a 

pointer pointing from the idenfrfication record to a utility, and 
lastly 3) a method of the utility (step 45). 

The system executes the method of the utility, which 
converts the data of the first fomnat to the data of the second 
25 format (step 46). 

The following example describes how the runtime system of the 
IWU proceeds when it receives a dialog primitive. 

In IWU each identification record is equipped with an ASN.1 op- 
30 eration ID as an ID value of a utility. If the dialog primitive is initiated from the 
SS7 network, it includes an ASN.1 operation ID. Then the operation ID stored 
in the dialog primitive can be used as a search key when searching the iden- 
tification record which has the same operation ID. Othenwise. if the dialog 
primitive is from CORBA, the operation ID is an IDL operation ID. Then the 
35 runtime system of the IWU uses the mapping rules to obtain the ASN.1 op- 
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eration ID corresponding to the IDL operation ID. With the ASN.1 operation 
ID, the runtime system of the IWU uses it as a search l^ey. 

The following example describes how the runtime system of the 
IWU proceeds when it has found an identification record as described above. 

5 In the IWU each identification record is equipped with: 1) a first 

pointer to the method of the utility, which method converts BER data to CDR 
data, and 2) a second pointer to the method of the utility, which method con- 
verts CDR data to BER. If the dialog primitive is initiated from the SS7 net- 
work, the runtime system of the IWU chooses the first pointer. Otherwise, if 

10 the dialog primitive is initiated from CORBA. the runtime system of the IWU 
chooses the second pointer. Then the runtime system of the IWU executes 
the method which is pointed to by the chosen pointer. 

Next we will describe in detail the operation of the compiler named 
15 "MAC". After that, we vwll describe the operation of the runtime system of 
IWU. 

The NAC compiler 

FIG. 6A shows the NAC compiler, which reads three input items 
and generates four output items. 
20 The NAC reads:' 

- A definition file set, which is composed of ASN.1 files, 

- class definitions from a BER library, and 

- class definitions from a CDR library. 
The NAC compiler generates: 

25 - an output file set for the C++ code; after compilation, the C++ 

code results in the utility set for BER-CDR conversions; 

- a second output file for Operation, En-or, and Extension Map 
Tables; these tables are used to obtain an appropriate utility for 
a current BER-CDR conversion; 

30 - a third output file for IDL-INAP mapping rules; these mapping 

rules are needed for obtaining an analogous INAP operation 
for an IDL operation, or vice versa; 

- a fourth output file for the initialization file set; this file set is 
used when creating an MSD list, which is the fifth output file. 
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The second, third, and fifth output files of the NAC compiler com- 
pose the selection mechanism for selecting the correct utility. The selection 
mechanism is used by the mntime system of IWU. 

The C++ code generated includes wrapper classes. The wrapper 
5 classes are also C++ classes, which are generated at the same time as other 
C++ code. The wrapper classes provide a method for decoding BER and 
encoding Into CDR, and a method for decoding CDR and encoding into BER. 
Both the methods execute the decoding and encoding In one phase, which 
makes the conversions more efficient. 
1 0 The above-mentioned MSD list, i.e. the Message Set Discriminator 

list, is used by the runtime system of IWU. In detail, an object named Mes- 
sage Set Discriminator of the runtime system of IWU uses the MSD list in 
order to find out to which message set each received message belongs. 

15 Generating the C++ code. In the NAC compiler two new methods 

are needed in order to create classes that convert BER to CDR and vice 
versa without ASN.1 instances and IDL instances. These methods are called 
AsnToCDR and CDRToAsn. The methods require the writing of an envelop- 
ing library "over the BER and the CDR libraries. The enveloping library. 

20 named Universal Type library, makes it possible to execute the conversions 
in one phase. 

The NAC compiler generates the C++ code for BER-CDR conver- 
sions. The C++ code includes a nested structure which comprises the follow- 
ing new methods: 

25 . CDRToAsn (in place of the BEncPdu method of the Snacc 

compiler) and 

- AsnToCDR (in place of the BDecPdu method of the Snacc 
compiler). 

The generated C++ code further includes these methods: 

30 - BEnc, 

- BDec, 

- BEncContent. and 

- BDecContent. 
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The BEnc and BDec methods are comparable to the methods of 
the Snacc compiler except for the extra parameters that are passed to the 
BEnc and the BDec. The BEncContent and BDecContent methods are ex- 
tended to include calls to the con^esponding CDR library method. 
5 Universalint is one of the wrapper classes that comprise the Uni- 

versal Type library. The NAC compiler uses the methods of a Universal type 
library when generating the code for BER-CDR conversions. The NAC 
compiler uses, for example, the Universalint wrapper class in addition to the 
Asnint class. 

10 In the code generation phase, the compiler generates a function 

call tree structure. The hierarchy structure of the generated code corre- 
sponds to the structure of the data types presented as input to the compiler. 
This means that depending on how the data types have been nested, the 
decoding routines of different data types call each other. For example, rf 
15 datatypel contains datatype2 in its structure, the decoding function of 
datatypel calls the decoding function of datatype2. 

The NAC compiler reads BER encoded ASN.1 data structures 
from its input files. These data stmctures are named briefly the BER data 
structures. The grammatical parser of the NAC compiler fomis an internal 
20 representation for each BER data structure. The internal representation is a 
tree structure in which the tree nodes con^espond to the fields of the BER 
data structure. If a field of the BER data structure is a structured field, then 
the node corresponding to that field has child nodes which may have their 
own child nodes. Child nodes having the same parent node are siblings. 
25 All nodes of said tree structure are function calls. The root node of 

the tree corresponds to the function which converts BER encoded data to 
CDR encoded data or vice versa. The child nodes of the root node corre- 
spond to the arguments which are passed as arguments to the function. 
Normally, one argument corresponds to the input stream, i.e. the bit stnng 
30 and another corresponds to the output stream. If an argument is a structured 
type, also the argument has child nodes. During a conversion all the nodes of 
the function call tree are passed through, which results in the conversion 
between BER encoded data and CDR encoded data. 
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The following example concerns principles which picture how the 
function call tree is composed. In the example. "structS" and "struct4" data 
structures have the same parent data structure, i.e. "structl". therefore, 
"structS" and "struct4" are siblings. The notation used is based on LISP. 
5 However, some other notation can be used as well. A BER data structure 
always includes a tag. a length, and a value. 

If a BER data structure is as follov^: 

TYPE1 

struct2 TYPE2 
-10 ENDTYPE1 

TYPE2 

structa TYPES 

struct4 TYPE4 
ENDTYPE2. 

15 

then its logical structure would be: 

(Tag1 Len1 (Tag2 Len2 (Tag3 LenS ValS Tag4 Len4 Val4))). 

Con-espondingly, its physical structure would be: 

{Tagl ,Len1 .Tag2,Len2.Tag3,Len3,Val3.Tag4.Len4,Val4}. 

20 In these structures each Tag' starts a type to be converted, each 

•ten' announces the length of the type, and each 'Val' announces the value 
stored to the type. 

Before calling a decodeLIST termed function, the contents of the 
BER stream is: 

25 {Tagl .Leni .Tag2.Len2.Tag3.Len3.Val3.Tag4,Len4,Val4} 

The decodeLIST function is called with the BERstream parameter 
and a CDRstream parameter, which is at first empty. The example below 
illustrates how the list. i.e. the input stream structure, is traversed during the 
decoding: 

30 BERstream := . . ^ w 1.11 

{Tagl ,Len1 .Tag2.Len2.Tag3.Len3.Val3.Tag4.Len4.Val4} 

.decodeLIST(BERstream,CDRstream) 
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decodeLIST(BERstream,CDRstream) 
{ 

detect TYPE 1 Tag (="Tag1") In BERstream 
CDR encode TYPE1 Tag to CDRstream 

r Extract TYPE1 Value from BERstream */ 
BERstream := TYPE1 Value from BERstream 



/* Here BERstream = 

{Tag2.Len2.Tag3.Len3.Val3.Tag4.Len4.Val4}*/ 



10 
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decodeTYPEI (BERstream.CDRstream) 

} 

decodeTYPEI (BERstream.CDRstream) 
{ 

detect TYPE 2 Tag (="Tag2") in BERstream 
CDR encode TYPE2 Tag to CDRstream 
r Extract TYPE2 Value from BERstream */ 
BERstream := TYPE2 Value from BERstream 

/* Here BERstream = {Tag3,Len3.Val3,Tag4,Len4,Val4> */ 
decodeTYPE2(BERstream,CDRstream) 

} 

25 decodeTYPE2(BERstream.CDRstream) 
{ 

r Here BERstream = {Tag3,Len3,Val3,Tag4,Len4.Val4} */ 

30 detect TYPE3 Tag (='Tag3") in BERstream 

CDR encode TYPE3 Tag to CDRstream 
r Extract TYPE3 Value from BERstream */ 
BERstream 1 := TYPE3 Value from BERstream 

35 I* Here BERstreamI = {Val3} */ 

decodeTYPE3(BERstream1 .CDRstream) 

/* This routine CDR-encodes Val3 to CDR stream */ 

detect TYPE4 Tag (='Tag4") in BERstream 
40 CDR encode TYPE4 Tag to CDRstream 

r Extract TYPE4 Value from BERstream */ 
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BERstream2 := TYPE4 Value from BERstream 
"r Here BERstream2 = {Val4} */ 

5 ciecodeTYPE4(BERstream2.CDRstream) 

r This routine CDR-encodes Val4 to CDR stream / 

} 

In the above, the target stream, e.g. the CDR encoded stream, is 
encoded, while the source stream, e.g. BER encoded stream, is being de- 
10 coded. However, the encoding and decoding is not restricted to BER and 
CDR fonnat, but applies to all fomiats. What is essential to the example 
above is that the conversion of the coding from one fonriat to the other is 
performed while parsing the coding of the source fomiat. The conversion Is 
embedded in the process of decoding the structure of the source format 
15 Further, it should be noted that the above example is quiescent 

about details related to the parameter passing, i.e. as to whether "call by 
value" or pointer parameters are used. 

The above example is quiescent on the specific issues related to 
the encoding of values and lengths in the target format stream, i.e. the 
20 GDRstream. The encoding can be perfomned differently. The BER data struc- 
ture shown above is also an example of a pre-order for a data structure. A 
post-order for the BER data structure would be: 

{Leni .Tag1 .Len2,Tag2.Len3.Val3,Tag3,Len4.Val4.Tag4} 

25 In the post-order, a 'Len' and a 'Val' are before a Tag'. In the pre- 

order. a Tag' is before a 'Len' and a Val'. A source format can be repre- 
sented in pre-order or in post-order, and a target fomiat can be represented 
In pre-order or in post-order. A source fomiat and a target format may have 
the same order, but they may also have different orders. 
30 A data structure of a target fomnat may include as many fields as a 

data structure of a source fomnat. However, it is also possible that a data 
structure of a target format has a different count of fields than a source for- 
mat. A logical structure of a target format may be the same as a logical struc- 
ture of a source forniat, but the logical structures may differ from each other. 
35 The above shown BER data structure includes two fields: 

'struct2.struct3' field for Val3* and 
'stnjct2.struct4' field for Val4.' 
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The BER data structure may be converted into the following CDR 
data structure: 

TYPES 

structe TYPES 
5 struct? TYPE? 

ENDTYPE5 
TYPE? 

stmctS TYPES 
ENDTYPE7 
10 TYPES 

structQ TYPE9 
ENDTYPE8 

In this case the CDR data sbucture has the same count of fields 
15 as the BER data structure but a different logical structure. The CDR data 
structure shown includes the following fields: 
'structS' field for ValS' and 
'struct?.struct8.struct9' field for 'Val4'. 

20 Here 'structS' does not include any nested structures. However, a 

data structure resulting from a conversion may include two nested data struc- 
tures, such as 'struct?.stnjct8.struct9', or the data structure may include more 
than two nested data structures. 

It is possible that the source format does not include any 'Len'. 

25 Then the length of the field may be concluded using a Tag'. Altematively, a 
'Val' may include a field end marker. For example, two bytes having the value 
0 may represent the field end marker. 

We have described above how a source fomnat and a target fonmat 
may differ from each other. In any case, the generation of a target format is 

30 executed by using the coding rules. The coding oiles include at least rules 
which map a Tag' of a source fomnat to a Tag* of a target fomnat. There may 
also be coding rules for mapping 'ten's and Val's. 

It is also possible that in the target forniat there are no data type 
tags for the data structure elements. Instead, the data types in the target 

35 fomnat couW be implicit from the context. This means, for instance, that the 
receiver of the target bit string knows, from the received message type or 
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Other indicators in the message, the data type structure to be applied for the 
target bit string. This means, for instance, that the receiver manipulates the 
received target bit string via a data type mask placed on top of the received 
bit string. 

5 Therefore, the only thing that Is needed in the encoding of a data 

stmcture element into the target format is to have the correct representation 
of its value i.e. Val' in the target bit string format. What is needed, is know- 
ledge of the target format coding representation for different data types. For 
example, given an ASN.1 SEQUENCE -structure, the representation for a 

1 0 sequence of elements in the target bit string needs to be known. 

Another example is how various general data types, such as inte- 
gers, floating numbers and byte strings, are encoded in the target fomiat. in 
the case of integers, what matters is the length of integers in the target for- 
mat, how the sign is encoded, and whether the most significant bit is the first 

15 or the last. In the case of floating numbers what matters is the encoding of 
the mantissa and the characteristics comprising their lengths etc. 

As in the description of the background of the invention, the follow- 
ing two examples concern the conversion of the ^InitialDpArg" named data 
20 structure, which is BER encoded. Again we are assuming that also the con^ 
sponding CDR data structure is named the "InitialDpArg". 

Again we are assuming that the definition for the "InitlalDP" opera- 
tion is a file named "operation.asn": 

25 CS1 OPErationTypes DEFINITIONS 

InitlalDP ::= OPERATION 
ARGUMENT InitialDPArg 
ERRORS { 

30 ...} 

InitlalDP OPE ::= OBJECT { 
&Arg InitialDPArg 
&Err{ 



...} 
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We are also assuming that the definition for InitialDPArg argument 
is given in another file that may be named "argument-asn": 

InitialDPArg ::= SEQUENCE { 
5 serviceKey [0] ServiceKey, 

redirectionlnformation [30] Redirection Information 
...} 

10 The output class is generated by using the definitions which are 

stored in the "operation.asn" file and the "argument.asn" file. The output 
class, written in its own file, is given below: 



class lnitialDPArg_c: public AsnType 
15 { 

public: 

struct lnitialDPArg_s { 

ServiceKey_c serviceKey; 

20 Redirectionlnformation_c *redirectionlnfomnation; 

lnitialDPArg_s(); 

lnitialDPArg_s (const lnitialDPArg_s &); 
~lnitialDPArg_s(); 

25 lnitialDPArg_s &operator = (const lnitialDPArg_s &); }: 

AsnType *CloneO const; 

AsnLen BEncContent (BUF_T b, CDRJNPUT_BUF c); 
Void BDecContent (BUF_T b.CDR_OUTPUT_BUF c, 

AsnTag Tag, AsnLen elmtLen, 
30 AsnLen &bytesDecoded); 

AsnLen BEnc (BUF_T b, CDRJNPUT_BUF c); 
Void BDec (BUF_T b, CDR_OUTPUT_BUF c, 

AsnLen &bytesDecoded); 



35 
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Static int CDRToAsn (BUF_T b. CDRJNPUT.BUF c, 

AsnLen &bytesEncocled); 
static int AsnToCDR (BUF_T b. CDR_OUTPUT_BUF c. 
AsnLen abytesDecoded); 
BEncPdu(BUF_T b,AsnLen &BytesEncoded): 
BDecPdu(BUF_T b.AsnLen &BytesDecoded); 



int 
int 

}; 



The output class contains the functions for BER-CDR conversions 
10 (AsnToCDR and CDRToAsn). Similarly, an output class corresponding to an 
en-or defined in the ASN file is written in its own file. 

Like the Snacc compiler, also the NAC compiler processes the 
data structure field by field, and it calls methods which generate ASN.1 C++ 
15 classes. 

Example 3: Generating the C++ code which converts BER to CDR 
(see FIG. 3B). 

The NAC compiler generates the C++ code for each 
20 field of the InitialDPArg data structure so that the code includes 

the following method calls of the Universal Type library in the fol- 
lowing order: 

- the BDecPdu and BDec method calls of the Inttial- 
DpArg class, 

25 - the BDecContent method call of the InitialDpArg 

class, which in turn calls the BDecContent method 
of the AsnType class. 
. The AsnToCDR method of the WrplnitialDpArg. 

30 Thus, there is only one phase in which the AsnToCDR method in 

the WrplnitialDpArg class is called (this phase is termed "1&2&3" in FIG. 3B). 
The other methods used in the C++ code generation are BDec and BDec- 
Content methods of the InitialDpArg class. 
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Example 4: Generating the C++ code which converts CDR to BER 
(see FIG. 3B). 

The NAC compiler generates a C++ code for each field 
of the InitialDPArg data structure so that the C++ code includes 
5 the following method calls of the Universal Type library in the fol- 

lowing order: 

- The CDRToAsn method of the WrplnitialDpArg. 

- The BEncContent method of the InltlalDpArg class, 
which in turn calls the BEncContent method of the 

10 AsnType class. 

- The BEnc and BEncPdu methods of the InitialDpArg 
class. 

FIG. 3D shows that BER encoded data are transfomied in one 
1 5 phase to CDR encoded data and vice versa. 

Now we can compare examples 3 and 4 to the examples 1 and 2 
described above. 

As shown In FIG. 3A, the Snacc compiler generates the ASN.1 
C++ classes, which include data types and encoding/decoding functions. At 
20 least some of these data types are used as an interface for the encod- 
ing/decoding functions. In other words, variables passed as arguments to the 
functions are accordant with the data types generated by the Snacc compiler. 
A programmer has to write the program "2A", which sets values to the vari- 
ables and passes the variables as arguments to the BER encoding functions. 
25 Program "2A" gets values from the variables that have been passed as ar- 
guments to the BER decoding functions. In addition, the programmer has to 
write programs "2B" and "2C'. 

As shown in FIG. 3B, the NAC compiler generates all the needed 
C++ code. The C++ code is compiled, and it results in the utility for the BER- 
30 CDR conversion. 

FIG. 3C describes how a generated utility may execute the BER- 
CDR conversions in prior art. In prior art, the BER-CDR conversions are 
executed in at least three phases. 

Correspondingly, FIG. 3D describes how a utility generated by the 
35 NAC compiler executes the BER-CDR conversions. The BER-CDR conver- 
sions are executed in one phase, which speeds the process of conversion. 
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Generating the Operation, Error and Extension Map Tables. A 

syntax transfer defines mappings between ASN.1 and CORBA. This mapping 
is executed as a runtime operation within iWU by using an IDL interface. 

The IDL interface Is needed to support syntax transfer. The NAC 
5 compiler reads ASN.1 macro definition files and generates the IDL interface 
so that: 

- each ASN.1 operation macro definition is mapped to an lUL 
operation, 

- each ASN.1 en-or macro definition is mapped to an IDL user 

10 exception, and 

- each ASN.I extension macro definition is mapped to an IDL 

construct. 

in addition, the NAC reads arguments to ASN.1 operations and 
ASN.1 data definitions (TypeDefs and Valuedefs) and generates the IDL 

15 interface so that: 

- each ASN . 1 argument is mapped to an IDL type, 

- each ASN.1 type definition is mapped to an IDL type definition. 

and 

- each ASN.1 value definition is mapped to an IDL value defini- 

20 tion. 

An ASN.1 en-or macro, an extension macro, an argument, a type 
definition, and a value definition mentioned above belong to some ASN.1 
operation macro. ASN.1 operation macros are mapped to INAP operations, 
which are mapped to IDL operations. Therefore ASN.1 operation macros can 
25 be mapped to IDL operations and vice versa. 

The ASN.1 extension macro mappings are more complex than the 
other ANS.1 mappings, and thus they are discussed more closely. 

An ASN.1 operation macro may include one or more extension 
30 macros. This kind of ASN.1 macro and its extension macros are mapped in 
an IDL operation. However, if an ASN extension macro includes so-called 
'ANV-values, also typecode information is needed. 

■ANY'-value is a value of an arbitrary type. Thus so called type- 
code infomiation must be related to an 'ANY-value in order to infomn a re- 
35 ceiver which kind of data the 'ANV-value includes. 
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The IDL interface is assigned to \he following tables, which are 
used to find the appropriate utility for the BER-CDR conversion: 

- an Operation Map Table, where function pointers for BER-CDR 
conversions are stored, 

5 - an En-or Map Table, where function pointers for BER-CDR 

conversions are stored (and used if an error occurs), and 

- an Extension Map Table for manipulating the typecode of the 
type present in the 'ANY-value which is passed in case of ex- 
tensions. 

10 The tables contain more infonnation than listed above. That infor- 

mation is listed fully below in connection with the description of a Message 
Set Discriminator, which is one object of the runtime system used in IWU. 

The typecode infbmnation is stored in the Extension Map Table 
consisting of the following parameters: 

15 - Extension Id, 

- Extension Name, 

- TypeCode Infomnation for the AsnType, 

- AsnToCdr function pointer for the AsnType, and 

- CdrToAsn fuiicTibri pointer for the AsnType. 

20 

All the parameters listed, except the typecode infomfiation. are 
given a value from the infonnation present in ASN.1 source files, or the value 
is generated by the NAC compiler. The typecode infonnation is obtained from 
an Interface Repository file. 

25 When a dialog primitive containing BER data anrives during run- 

time, the dialog primitive may include 'ANY-value and an ExtensionlD. By 
using the ExtensionlD as a key, the appropriate typecode infomnation is ob- 
tained from the Extension Map Table, and the appropriate AsnToCDR func- 
tion pointer is found firom the Extension Map Table. Then 'ANY-value is 

30 converted to CDR data by using the AsnToCDR function, and the CDR data 
and the type code infomnation are sent to a receiver. 

Con-espondingly, when a dialog primitive containing CDR data ar- 
rives during runtime, it may include 'ANY-value and an ExtensionlD. By 
using the ExtensionlD as a key. the appropriate CDRToAsn function pointer 

35 is found in the Extension Map Table, and the CDRToAsn function is used 
when converting the 'ANY-value to BER-data. 
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Generating the IDL-INAP mapping rules. IDL operations may be 
classified as synchronous and asynchronous operations. Altematively. the 
IDL operations may be classified according to what a perfomier of an IDL 
operation is expected to report. 
5 Both of these classifications are taken into consideration in the fol- 

lowing IDL operation classification defined by ITU. 

Class 1 : Synchronous, reporting success or failure (result /enror) 
Class 2: Asynchronous, reporting success or failure (result /error) 
Class 3: Asynchronous, reporting failure (en-or) only 
1 0 Class 4: Asynchronous, reporting success (result) only 

Class 5: Asynchronous, outcome not reported 
The following INAP operation classes are defined by ITU. 
Class 1: ANS.1 operation macro reporting result and error 
Class 2: ANS.1 operation macro reporting error only 
15 Class 3: ANS.1 operation macro reporting result only 

Class 4: ANS.1 operation macro reporting neither result nor error 

IDL and INAP operation classes have to be mapped in some way 
to enable BER-CDR conversions. The NAC compiler maps the operation 

20 classes in the following way: 

- IDL operation class 1 is not mapped to any INAP class 

- IDL operation class 2 is mapped to INAP class 1 

- IDL operation class 3 is mapped to INAP class 2 

- IDL operation class 4 is mapped to INAP class 3 
25 . IDL operation class 6 is mapped to INAP class 4 

In addition to providing the optimised transfer syntax i.e. encoding 
conversion for data structures defined using ASN.1 definition language, the 
compiler, In an embodiment of the invention also produces IDL definitions 
30 from the ASN.I language definitions. The mentioned coding rules are used in 
this conversion. Therefore, the coding rules are used to convert the ASN.1 
definitions to IDL definitions. The produced IDL is an instance of the original 
ASN.1 definition produced using coding rules. 

35 
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Generating the initialization file set. Below is a brief example of 
an initialization file generated by the MAC compiler: 
// F5INAP message set 
#include "asn-incl.h" 
5 #inciude "Map.hh" 

#include "String.hh" 
#include "fSinopgx-OpMap.h" 
#include "fSinergx-EnrorMap.h" 
class \AnpnbMapRow { 

10 public: 

OTC_String messageSetName; 

;^snOid *ptr2ApplContextNames; 

OTC_String repld; 

OpMapContainer *ptr20pMap; 

15 ErrorMapContainer *ptr2ErrorMap; 

ExtensionMapContainer *ptr2ExtMap; 

}; 

etc 

20 The runtime system of the IWU ... * * 

FIG 6A shows objects of IWU. or more particularly, the objects of 
the runtime system of the IWU which deal with the selection mechanism and 
execute BER-CDR conversions. FIG. 4A. which represents a general system 
for conversions, and FIG. 6A. have the following correspondence: 
25 - the utility set for BER-CDR conversion in FIG. 6A corresponds 

to the utility set for conversions in FIG. 4A, 
. the Operation, the Error, and the Extension Map Tables in FIG. 
6A correspond to the identification records in FIG. 4A. 

- IDL-INAP mapping rules in FIG. 6A correspond to the mappmg 

30 rules in FIG. 4A, and 

- the MSD list in FIG. 6A corresponds to the context set records 

in FIG. 4A. . « 

The runtime system of the IWU deals with associations between 
applications. These associations are termed ROP associations. Each ROP 
35 association is related to one dialog. 
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FIG. 5 Shows IWU and TCAP processes composing a bridge be- 
tween the SS7 networl< and CORBA. They communicate with each other 

using a shared memory. 

The HOP Engine shown in FIG. 5 consists of the Service Session 
5 Manager object and the Message Set Server object. It provides an interface 
for the applications that need to communicate using CORBA standard inter- 
operability. Therefore IWU can act as a CORBA client or a CORBA server. 
Con^espondingly, TCAP can act as a client or a server of the SS7 network. 

FIG. 5 depicts the six most relevant objects of the mntime system 
10 used in the IWU. Below, the operation of each object is discussed. 

(1) A Service Session Manager handles dialog primitives. It is re- 
sponsible for handling dialogs between TCAP and SLEs. Here are some 

examples of such dialogs. 
15 When TCAP receives an SS7Begin dialog primitive in a message 

from an application of the SS7 network, it creates a record of an SS7Begin 

event and stores it into the shared memory. 

The Service Session Manager receives the record of the 

SS7Begin event from the shared memory. Then the IWU creates a new ROP 
20 association and infonns the SLE about the-new ROP association by sending 

a message. 

Finally, the SLE may temfiinate the ROP association by sending an 
SS7End dialog primitive in a message. In that case, the Service Session 
Manager creates a record of the SS7End event and stores it in the shared 
25 memory When TCAP receives the record of the SS7End event from the 
shared memory, it infonns the SS7 network about the tem^ination of the ROP 
association by sending a message. 

Correspondingly, when the IWU receives an SLEBegin dialog 
primitive in a message from an SLE. it creates a new ROP association. The 
30 IWU creates a record of an SLEBegin event and stores it into the shared 
memory Then TCAP receives the record of the SLEBegin event from the 
shared memory and informs an application of the SS7 network of the new 
ROP association by sending a message. 

35 
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(2) A Message Set Server handles dialog primitives. It is responsi- 
ble for the handling of BER data before sending a message to an SLE, or 
when receiving a message from an SLE. The Message Set Server (MSS) 
communicates with the remote MSS located In a certain SLE. This MSS and 
5 the remote MSS communicate by using GlOP messages. 

The MSS receives a dialog primitive and pointers to the Operation 
Map Table, the Error Map Table, and the Extension Map Table from the ROP 
Handler, and the ROP handler receives the pointers from the Message Set 
Discriminator. 

10 The MSS uses the pointers when choosing the appropriate 

method for converting data stored in the dialog primitive. The MSS obtains an 
operation ID and an operation class from the dialog primitive received. 

The operation class defines which table the MSS must use. For 
example, if the operation class is "error", the MSS uses the Error Map Table. 

15 The Operation, Error, and Extension Map Tables are equipped 

with an ASN.1 operation ID. Thus, if the dialog primitive is from the SS7 
network, it includes an ASN.1 operation ID which can be used as a search 
key. Othenwise, if the dialog primitive is from CORBA, the MSS uses IDL- 
INAP mapping rules to obtain a corresponding ASN.1 operation ID. After 

20 receiving the ASN.1 operation, ID the MSS searches the table (e.g. the Error 
Map Table) for a record which has the same ASN.1 operation ID. 

In this phase the MSS has pointers to an appropriate utility. The 
MSS has to detemnine a conversion direction. If the dialog primitive is from 
the SS7 network, the conversion direction is from BER to CDR. Otherwise, 

25 ttie conversion direction is from CDR to BER. 

According to the conversion direction, the MSS selects from the 
record a pointer to an AsnToCDR method or a pointer to a CDRToAsn 
method. Lastly, the MSS converts data of the dialog primitive by using the 
method of the appropriate utility. 

30 

(3) The Shared Memory Handler writes and reads records of the 
events in the shared memory. Any object can use it that is intended for read- 
ing or storing the records of the events. The Shared Memory Handler assigns 
a sequence number to each record of an event and writes it in the shared 
35 memory. Once the event has been property dealt with, it deletes the record of 
the event from the shared memory. 
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(4) An ROP Association IV/lanager object is responsible for ROP 
associations. An ROP association forms a logical binding between two appli- 
cations. Eacli ROP association includes the dialog ID. the originating point 
code and the destination point code, references of the local and remote Ser- 
5 vice Session Manager, etc. 

The ROP Association Manager provides means for creating, updat- 
ing, and ending the ROP associations for events coming from TOAP or the 
SLE. 

10 (5) The ROP handler executes BER-GDR conversions between 

TCAP and an SLE by using the MSS. 

At the beginning of a dialog, when the ROP Handler receives an 

SS7Begin or a SLEBegin, it uses the Message Set Discriminator to obtain 

the Operation Map, Error Map, and Extension Map Table pointers. After that 
15 it transmits said pointers and a dialog primitive to the MSS, which executes 

required BER-CDR conversion for data stored in the dialog primitive. 

(6) The Message Set Discriminator differentiates between the 
message- sets. In addition, it simultaneously operates as an initialization 
20 process as shown in FIG. 4A. 

As described above, the NAG compiler creates the Operation Map 
Table, the Error Map Table, and the Extension Map Table, and the initializa- 
tion functions for them. The message set discriminator initializes the tables 
by using the initialization functions at the time of the IWU startup. 
25 The Initialization of the tables is canied out by reading initialization 

values and by calling the initialization functions with the initialization values. 
The initialization values are stored in certain initialization files. Each message 
set has its own initialization file. 

The Message Set Discriminator also maintains certain fields of the 
30 Operation Map Table, Error Map Table, and Extension Map Table. The ta- 
bles are maintained by adding a new entry to the LDAP directory or deleting 
an entry from the LDAP directory. 

The records of the Operation Map Table, the En-or Map Table, and 
the Extension Map Table include pointers pointing to encoding and decoding 
35 functions. The pointers in the tables enable the calling of an exact encod- 
ing/decoding function for the current dialog primitive. 
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The Extension Map Table contains the following parameters: 
. An ID parameter, which maps an extension to the invoked op- 
eration, 

- An Extension name parameter, which declares the name of the 
5 extension, 

- A Typecode information, and 

- An Extension value parameter, which consists of two functions 
vtfith pointers to methods for BER-CDR conversions. 

10 Whenever an SS7Begin (or SLEBegIn) anives, the ROP Handier 

calls the Message Set Discriminator to determine the message set. 

The Message Set Discriminator discriminates among message 
sets by comparing the attribute values of SSTBegin (or SLEBegin) to the 
parameter values of the MSD list (Message Set Discriminator list). 

15 

The SSTBegin (or SLEBegin) contains the following attnbutes: 

- The EventType describes the type of the primitive. 

- The Dialogid is used to uniquely identify dialogs. 

- The DestinationAddress describes ihe destination address of 
20 the particular dialog which address consists of the following six 

fields: 

- "Length" is the length of the address. 

- "Addresslndication" indicates the type of the address Infor- 
mation contained. 

25 . "PointCodeH" is the second octet of the Signaling Point 

Code. 

- "PointCodeL" is the first octet of the Signaling Point Code. 

- "SSN" is the Sub-System Number. 

- "GlobalTitle" is an identifier. 

30 - The OriginatingAddress describes the originating address of 

the particular dialog and consists of the previous six fields. 

- The ComponentPresent is set to TRUE if components are pre- 
sent along with the dialog; othenwise it is set to FALSE. 

- The QualityOfService can be INAP operation class 0 or INAP 
35 operation class 1 . 
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- The IsPDU is set to TRUE if the dialog PDU is present along 
with the dialog, otherwise it is set to FALSE. 

- The PDULenght discloses the Length of the dialog PDU. 

- The PDU is a pointer towards the dialog PDU. 

5 

Thus, the dialog PDU is optional; it may or may not be included in 
the SS7Begin (or SLEBegin) message. 

The Addresslndication indicates the type of address information. 
1 0 The Addresslndication field is set as one of the following types: 

- 'PC when the PointCodeH and PointCodeL fields indicate the 
address. 

- 'PC and SSN' when the PointCodeH and PointCodeL fields 
and the Sub-System Number field indicate the address. 

1 5 - 'GT when the GlobalTitle indicates the address. 

- 'GT and SSN' when the GlobalTitle field and the Sub-System 
Number field indicate the address. 

The MSB list coTisists of records, wherein each record contains 
20 the following parameters: 

- Message Set Version Name, 

- Originating Point Code, 

- Originating Sub-System Number, 

- Originating Global Title, 
25 - Destination Point Code, 

- Destination Sub-System Number, 

- Destination Global Title, 

- User Information, 

- Pointer to Application Context Names, 
30 - Repository ID, 

- Pointer to Operation Map Table, 

- Pointer to Error Map Table, 

- Pointer to Extension Map Table. 

The parameters listed above from the parameter "Message Set 
35 Version Name" down to the parameter "User Inforniation" are read In the 
LDAP directory. The LDAP directory is read when initializing the IWU. 
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The rest of the parameters listed above are obtained from certain 
initialization files. There is an initialization file for each message set. These 
files are used when the IWU is being set up. 

5 FIG. 6C shows the SS7Begin (or SLEBegin) attributes, the dialog 

PDU, the MSD list parameters, and the application context names 1,...,k. 
FIG. 6C also illustrates three MSD list records; the MSD may contain more 
than three records, however. 

Thus, the message set discrimination is based on the comparison 
10 of certain attribute values of the SS7Begin (or SLEBegin) with certain pa- 
rameter values of the MSD list records. 

The matching message set is determined by using one of the fol- 
lowing alternatives when comparing the values: 

1. the user information and the application context name, 
15 2. the Originating/Destination information and the application con- 

text name, and 
3. the Originating/Destination information 
with certain parameter values of the MSD list records. 
-T--. , r- T|^3 fjp3t alternative is preferred, and then the second alternative. If 
20 -the first and the second alternatives are not available, then the third alterna- 
tive is used. 

FIG. 6B shows that the first alternative is available when the dialog 
PDU of the SS7Begin (or SLEBegin) exists, and the dialog PDU includes the 
25 application name. If the dialog PDU exists but it does not include the applica- 
tion name, then the second alternative is used. If the dialog PDU is missing, 
the third alternative is used. 

When the first alternative is available: 

- the user information received from the dialog PDU of 
30 SSTBegin or SLEBegin is compared to the User Information of 

the MSD list records, and 

- the application context name received from the dialog PDU of 
SS7Begin or SLEBegin is compared to the names which are 
received by using the Pointer to Application Context Names of 

35 the MSD list records. 

In FIG. 6C dashed lines illustrate these cases of comparison. 
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When the second alternative is available, the application context 
name is compared in a manner described above. 

When the second or third altemative is used, the Originating/ Des- 
tination infonnation received from the SS7Begin (or SLEBegIn) is compared 
5 to the Originating/ Destination infomriation of the USD list as follows: 

- If the dialog is initiated by the TCAP. the Originating-Address 
attribute is compared to the Origination infonnation of the MSD 
list. 

- If the dialog is initiated by the SLE, the DestinationAddress at- 
10 tribute is compared to the Destination information of the MSD 

list. 

The comparison of the Originating/Destination information is 
based on the type which is stored in the Addresslndication field of the 
SSTBegin (or SLEBegin): 

- If the type is 'PC. the PointCodeH and PointCodeL fields are 
compared to the Originating/Destination Point Code. 

- If the type is 'PC and SSN', the PointCodeH and PointCodeL 
fields are compared to the Originating/Destination Point Code, 
and the Sub-System Number is compared to the Originat- 
ing/Destination Sub-System Number. 

- If the type is 'GT, the GlobalTitle is compared to the Originat- 
ing/Destination Global Title. 

- If the type is 'GT and SSN'. the GlobalTitle is compared to the 
Originating/Destination Global Title, and the Sub-Syistem Num- 
ber is compared to the Originating/Destination Sub-System 
Number. 

When the attribute values of the SS7Begln (or SLEBegin) and the 
30 parameter values of the MSD list record match, the connect MSD list record is 
found. As described above, each MSD list record contains pointers to the 
Operation, En-or, and Extension Map Tables. As described above, the ROP 
handler transmits those pointers to the MSS. 
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Claims 

1. A method for performing data structure conversions in a com- 
munications system, wherein at least one data structure comprises at least 
two elements located in a predetemnined order in the data structure which is 
5 defined for communication by a definition language and represented in the 
communication as bit strings, and wherein a source bit string confonrjing to a 
first format is converted into a target bit string conforming to a second fomnat. 

characterized in that the method comprises the following 

steps: 

10 browsing the source bit string, 

identifying In the source bit string each data structure element of 
the data structure without parsing the source bit string, 

handling the identified data structure elements in the same order 
as they are located in the data structure, said handling to include decoding 
15 each data stmcture element from the source bit string and encoding the 
decoded data structure element directly into the target bit string. 

2. A method as defined in claim 1 , c h a r a c t e r I z e d in that 
the decoding is perfomied by a decoding function and the encoding Is per- 
formed by an encoding function, wherein each function is utilized through a 

20 function call and said functions are generated by using coding rules and 
definitions in accordance with the definition language. 

3. A method as defined In claim 2. characterized in that. In 
addition, a wrapper function is generated by applying the coding rules and 
the definitions so that the wrapper function includes the function call of the 

25 decoding function and the function call of the encoding function. 

4. A method as defined in claim 1. wherein the definition language 

isASN.1. 

5. A method as defined in claim 1, wherein the definition language 

Is IDL 

30 6. A method as defined in claim 1 , wherein the first format is BER. 

7. A method as defined in claim 1 . wherein the second fomnat Is 

CDR. 

8. A method as defined in claim 1, characterized in that 
the data structure element includes a tag for Identifying the data stiiicture 

35 element and a value stored in the data structure. 
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9 A method as defined in claim 8, c h a r a c t e r i z e d in that 
the data structure element further includes length infomnation indicating the 
length of the value within the data structure element. 

10 A method as defined in claim 1, c h a r a c t e r i z e d in that 
5 the steps are executed by a utility of a utility set. each utility of the utility set 

being created by using at least two class libraries containing classes and a 

certain definition file containing definitions. ^ . ♦ 

11 A method as defined in claim 10, characterized in that 

when creating the utilities of the utility set, one utility at a time, the following 
10 steps are executed until the definitions of the definition file are read: 

reading a definition from the definition file and writing it into a 

memory, . . . . 

parsing the written definition, whereby a parsed class name is ob- 
tained as a result of the parsing, 
15 reading a first class corresponding to the parsed class name from 

a first class library and writing the first class into the memory, 

reading a second class corresponding to the parsed class name 
from a second class library and writing the second class into the memory. 

generating afleast one wrapper class, which is adapted to call at 
20 least one method of the first class and at least one method of the second 
class, wherein said methods handle data of the same context. 

reading each wrapper class, the first class, and the second class 
from the memory and writing them into an output file set. and 

compiling the output file set by using a suitable compiler, which 
25 compiling results in a utility of the utility set. . . 

12. A method as defined in claim 11 . c h a r a c t e r i z e d by the 

further steps of: 

generating an identification record in response to the definition 
read from the definition file, which identification record includes at least one 

30 pointer pointing to a utility and 

writing the identification record into a second output file. 
1 3 A method as defined in claim 1 1 , c h a r a c t e r i z e d in that. 
In order to enable several simultaneous dialogs composed of dialog primi- 
tives, the method includes the further steps of: 
35 generating a mapping rule in response to the definition read, which 

mapping rule maps a first identifier of a first dialog primitive to a second iden- 
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tifier of a second dialog primitive, wherein the first dialog primitive is used by 
a first application and the second dialog primitive is used by a second appli- 
cation, 

writing the mapping rules generated into a third output file. 
5 14. A method as defined in claim 1. c h a r a c t e r i z e d by the 

further steps of: 

generating data for a context set record in response to the defini- 
tion read, which data include attribute values relating to a certain context set, 
and 

1 0 writing the date into a fourth output file. 

15. A method as defined in claim 14. c h a r a c t e r i z e d in that 
in creating the context set records, the method includes the fijrther steps of: 

reading the data stored in the fourth output file, 
generating a context set record which includes at least one pointer 
1 5 pointing to an identification record and stored in the second output file, and 
writing the context set record into a fifth output file. 

16. A method as defined in claim 12, 13, and 15, 
characterized by constructing a selection mechanism from 

- the Identification records stored in the second output file, from the mapping 
20 rules stored in the third output file, and fomn the context set records stored in 
the fifth output file, whereby the communications system includes functions of 
handling a dialog between a first application and a second applica- 
tion, wherein the first application receives and transmits data of the first for- 
mat, and wherein the second application receives and transmits data of the 

25 second forniat. and 

executing data conversions for the dialog primitives by using the 

utility set through the selection mechanism. 

17. A method as defined in claim 16, characterized in that 
the dialog primitives are located in messages which are used in the commu- 

30 nication. 

18. A method as defined in claim 16, c h a r a c t e r i z e d in that 
the dialog primitives are located in event records which are used in the com- 
munication. 

19. A method' as defined in claim 16. characterized in that 
35 in response to receiving a dialog primitive which is initially from the first 

application and which starts a dialog between the first application and the 
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cation and which starts a dialog between the first application and the second 
application; 

comparing attribute values of the dialog primitive to attribute val- 
ues of the context set records which are stored in the fifth output file and 
5 hereby, 

finding a context set record with the best match, wherein certain 
attribute values are the same as the attribute values of the dialog primitive, 

obtaining at least one pointer pointing from the context set record 

to an identification record, and 
10 transferring a second dialog primitive, which is intended for the 

second application, wherein the second dialog primitive notifies that the dia- 
log has started. 

20. A method as defined in claim 16, c h a r a c t e r i z e d in that 
when the dialog has started, within the communications system: 
15 receiving a first dialog primitive which is initially from the first 

application, 

obtaining a first identifier from the first dialog primitive, 
obtaining a second identifier from a mapping rule stored in the fifth 
output file, which mapping rule maps the first identifier and the second identi- 
20 fier; and according to the second identifier. 

generating a second dialog primitive, which conresponds to the 

first dialog primitive, and 

obtaining data of the first format from the first dialog primitive, con- 
verting the data of the first fomnat to data of the second fonnat. and storing 
25 the data of the second forniat into the second dialog primitive, and 

transferring the second dialog primitive which is intended for the 

second application. 

21 . A method as defined in claim 20, c h a r a c t e r i z e d in that 
the data of the first format is converted to data of the second fomiat by 
30 using a pointer pointing from the context set record to an 

identification record, 

using a pointer pointing from the identification record to a method 

of a utility, and 

executing the metinod of the utility. 
35 22. A utility for perfomning data stiucture conversions in a 

communications system, wherein at least one data structure comprises at 
least two elements located in a predetemiined order in the data structure 
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elements located in a predetermined order in the data structure which is 
defined for communication by a definition language and represented in the 
communication as bit strings, the utility being adapted to convert a source bit 
string confonning to a first fomiat into a target bit string confomning to a sec- 

5 ond format, 

characterized in that the utility comprises: 

means for browsing the source bit string, 

means for identifying a first data structure element in the source bit 

string, . 
10 means for handling identified data structure elements in the same 

order as they are located in the data structure without parsing the source bit 
string said means for the handling being adapted to decode each data struc- 
ture element from the source bit string and encode the decoded data struc- 
ture element directly into the target bit string. 
-,5 23. A utility as defined in claim 22, c h a r a c t e r i z e d in that 

said means for handling the identified data structure elements include a de- 
coding function and an encoding function, wherein each function is utilized 
through a function call and said functions are generated by applying coding 
rules and definitions in accordance with the definition language. 
20 24. A utility as defined in claim 22, c h a r a c t e r i z e d in that, in 

addition, the utility is adapted to generate a wrapper function by applying the 
coding rules and the definitions so that the wrapper function includes the 
function call of the decoding function and the function call of the encoding 
function. 

25 25. A utility as defined in claim 22. wherein the definition language 

26. A utility as defined in claim 22. wherein the definition language 

27. A utility as defined in claim 22. wherein the first format is BER. 
30 28. A utility as defined in claim 22, wherein the first format is CDR. 

29. A utility as defined in claim 22. c h a r a c t e r i z e d in that 
the first data stmcture element includes a tag for identifying the first data 
structure element and a value stored in the first data structure. 

30. A utility as defined in claim 22, c h a r a c t e r i z e d in that 
35 the first data structure element further includes length infonnation indicating 

the length of the value. 



is ASN.1. 
is IDL. 
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31 . A compiler for creating utilities for a utility set by using at least 
two class libraries containing classes and a certain definition file containing 
definitions, the utilities being adapted to perfonn data structure conversions 
in a communications system, wherein at least one data structure comprises 
5 at least two elements located in a predetermined order in the data structure, 
which is defined for communication by a definition language and represented 
in the communication as bit strings, 

characterized in that the compiler comprises: 

means for reading a definition from the definition file and writing it 

10 into a memory, 

means for parsing the writing definition, whereby a parsed class 

name is obtained as a result of the parsing, 

means for reading a first class con-esponding to the parsed class 
name from the first class library and writing the first class into the memory, 
15 means for reading a second class con-esponding to the parsed 

class name from the second class library and writing the second class into 
the memory, 

means for generating at least one wrapper class, which is adapted 
to call at least one mfethod of the first class and at least one method of the 
20 second class, wherein said methods handle data of the same context, 

means for reading each wrapper class, the first class, and the 
second class from the memory and writing them into an output file set, 
whereby the output file set results in a utility which is adapted to 

browse a source bit string, 
25 identify data structure elements in the source bit string, and 

handle identified data structure elements in the same order as 
they are located in the data structure without parsing the source bit string, 
and during the handling, decode each data structure element from the source 
bit string and encode the decoded data structure element directly into the 

30 target bit string, 

32. A compiler as defined in claim 31. c h a r a c t e r i z e d in that 

the compiler further comprises: 

means for generating an identification record in response to the 
definition read, which identification record Includes at least one pointer point- 
35 ing to a utility, and 

means for storing the identification record. 
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33. A compiler as defined in claim 31 . c h a r a c t e r i z e d in that 
in order to enable several simultaneous dialogs to be composed of dialog 
primitives, the compiler further comprises: 

means for generating a mapping rule In response to the definition 
5 read, which mapping rule maps a first identifier of a first dialog primitive to a 
second Identifier of a second dialog primitive, wherein the first dialog primitive 
is used by a first application and the second dialog primitive is used by a 
second application, and 

means for storing the mapping rule. 
10 34. A compiler as defined in claim 31 . c h a r a c t e r i z e d in that 

the compiler further comprises: 

means for generating data for a context set in response to the 
definition read. which data include attribute values related to a certain context 
set, and 

15 means for writing the data into a fourth output file from which the 

data is be the read by an initialization process and generated to context set 
records, wherein each context set record includes at least one pointer point- 
ing to an identification record. 

35. A system for perfomning data structure conversions in a com- 
20 munications system, wherein at least one data stmcture comprises at least 
two elements located in a predetemiined order in the data structure which is 
defined for communication by a definition language and represented in the 
communication as bit strings, the system being adapted to handle several 
simultaneous dialogs composed of dialog primitives, 
25 characterized in that the system comprises: 

a utility set for executing the data structure conversions, the utility 
set being composed of utilities, each utility being adapted to identify data 
structure elements in a source bit string and handle the identified data struc- 
ture elements in the same order as they are located in the data structure 
30 without parsing the source bit string, and during the handling, decode each 
data structure element from the source bit string and encode the decoded 
data structure element directiy into a target bit string. 

36. A system as defined in claim 35, c h a r a c t e r i z e d in tiiat 

the system furtiier comprises: 
35 a selection mechanism for selecting a utility from tiie utility set. the 

selection mechanism being composed of identification records, mapping 
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rules and context set records, wherein each identification record includes at 
least one pointer pointing to a utility and each mapping rule maps a first iden- 
tifier of a first dialog primitive and a second identifier of a ^^^"^^^f ^ P":"; 
tive. wherein the first dialog primitive is intended for transmrtting data of a first 
format, and the second dialog primitive is intended for transmitting data of a 
second fomiat. and wherein each context set record includes at least one 
pointer pointing to an identification record. 

37.Asystemasdefinedinclaim36.characterized inthat 

the system further comprises: 

means for handling a dialog between a first application and a sec- 
ond application, wherein the first application receives and transmrts data of 
the first fomiat and the second application receives and transmrts data of the 
second format, the means being adapted to perfomi the data structure con- 
versions for the dialog primitives by using the utility set through the selection 

15 mechanism. . . ^ 

38 Asystemasdefinedinclaim37.characterized inthat 

the dialog primitives are located in messages which are used in the commu- 

nication. ^ . j :„ tK^t 

39 Asystemasdefinedinclaim37.charactenzed inthat 

20 the dialog primitives are located in event records which are used in the com- 

munication. . , .„xi,-t 

40. A system as defined in claim 37, c h a r a c t e r i z e d in that 

the system further comprises: 

means for comparing attribute values of the dialog pnmitive to at- 
25 tribute values of the context set records, and said means being adapted to 
find a context set record with the best match, wherein certain attribute values 
are the same as the attribute values of the dialog primitive, and to obtain at 
least one pointer pointing from the context set record to an identification 

record, and ... u • * ..m^a 

■ 30 means for transferring a second dialog primitive which is intended 

for the second application, wherein the second dialog primitive notifies that 

the dialog has started. . 

41 . A system as defined in claim 37. c h a r a c t e r i z e d in that 

the system further comprises: 
35 means for receiving a first dialog primitive which is initially from the 

first application, 
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means for obtaining a first identifier from the first dialog primitive 
and obtaining a second identifier from a mapping rule stored in the fifth out- 
put file, which mapping rule maps the first identifier and the second identifier, 

means for obtaining data of the first fonnat from the first dialog 
5 primitive, converting the data of the first format to data of the second fomiat, 
and storing the data of the second format into the second dialog primitive, 
and 

means for generating a second dialog primitive, which con-e- 
sponds to the first dialog primitive, and 
10 means for transferring the second dialog primitive which is in- 

tended for the second application. 

42. A method as defined in claim 41. characterized in that 
the means for obtaining data of the first format, converting the data of the first 
format to data of the second format, and storing the data of the second for- 
15 mat, are adapted to 

use a pointer pointing from the context set record to an identifica- 
tion record, 

use a pointer pointing from the identification record to a method of 
a utility, and ' ' — ^- 

20 execute the method of said utility. 
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